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REMARKS 

Reconsideration and allowance of the subject application are respectfully requested. 

Claims 35-37 are canceled thereby rendering moot the rejection under 35 U.S.C. §101. 

All claims 1-41 stand rejected under 35 U.S.C. §102 as being anticipated by newly- 
applied Puuskari. This rejection is respectfully traversed. 

To establish that a claim is anticipated, the Examiner must point out where each and 
every limitation in the claim is found in a single prior art reference. Scripps Clinic & Research 
Found, V. GenenteCy Inc., 927 F.2d 1565 (Fed. Cir. 1991). Every limitation contained in the 
claims must be present in the reference, and if even one limitation is missing from the reference, 
then it does not anticipate the claim. Kloster Speedsteel AB v. Crucible^ Inc., 793 F.2d 1565 
(Fed. Cir. 1986). Puuskari fails to satisfy this rigorous standard. 

Puuskari describes a method for controlling a quality of service in a mobile 
communications system. The abstract refers to a dynamic packet-based quality of service (QoS) 
mechanism "within a transmission tunnel defined by a more static packet data protocol context 
(PDP context). More particularly, each data packet is arranged to carry at least one QoS 
parameter, and the scheduling and the policing of the transmission of the data packets is made in 
packet by packet basis according to this QoS information in the packets, while, however, within 
the limits set by the PDP context." In Puuskari^s packet-by-packet method, "the QoS can be 
changed at any time after activation of the PDP context, since only the QoS information in the 
relevant data packets has to be changed." See Abstract. 

The claims address the problem of how to establish an RSVP protocol proxy relationship 
in a multimedia session involving a mobile communication access network in a non-RSVP 
enabled mobile terminal. RSVP is a protocol developed for use with the wired line internet. No 
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special provisions are established in RSVP signaling, which create difficulties in mobile 
communications with non-RSVP enabled mobile radio terminals. Puuskari is not concerned with 
this problem of non-RSVP enabled mobile radio terminals. But the inventors of the instant 
application recognized this problem and provided a mechanism that allows a non-RSVP enabled 
mobile terminal to communicate a protocol proxy request with an RS VP-enabled node along the 
send-receive path between the mobile terminal and a remote host. 

Amended claim 1 emphasizes that the mobile terminal initially "determines a need for a 
communications protocol proxy for the mobile terminal for the multimedia session." This 
feature is missing in Puuskari. The text referred to by the Examiner at column 7, lines 49-58 and 
column 8, lines 24-28 relates to establishing a PDP context in the mobile station (MS), the 
SGSN, and the GGSN. There is nothing describing that the mobile recognizes that it is not 
RSVP-enabled and therefore needs an RSVP proxy for the session. 

The "Activate PDP Context Request" message referred to by the Examiner "gives 
information on the TLLI, PDP type, PDP address, required QoS and NSAPI, and optionally the 
access point name APN." Column 8, lines 24-28. None of this information "indicat[es] that the 
access point should function as a commxmications protocol proxy for the mobile terminal for a 
media data stream of the multimedia session," as recited in claim 1. Moreover, the fact that the 
GGSN is a gateway node does not mean that it is an RSVP proxy for the mobile. The mobile in 
Puuskari could be RSVP-enabled, in which case the GGSN would not need to be the mobile's 
proxy. 
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Claim 1 also includes features from 3-6: 

• the communications protocol is the resource reservation protocol (RSVP), and the 
communications protocol proxy is an RSVP proxy for the mobile terminal during 
the multimedia session, 

• the request message is a Packet Data Protocol (PDP) context request message and 
the indicator is an RSVP proxy flag, and 

• the PDP context request message includes the RSVP proxy flag as a PDP 
configuration option (PCO)." 

In rejecting claims 3-6, The Examiner refers to portions of columns 15 and 16 where Puuskari 
teaches using the RSVP protocol. But there is no teaching of the mobile in Puuskari determining 
that it needs the GGSN to be its RSVP proxy and then sending a message requesting the GGSN 
to be its RSVP proxy. The messages described in the referred to column 15 and 16 text are 
RSVP messages. The request message in claim 1 is not an RSVP message, but rather a PDP 
request message. The RSVP proxy request flag is in the PDP context request message. Indeed, 
claim 1 even recites that the "the RSVP proxy flag as a PDP configuration option (PCO)." The 
PDP context request message in Puuskari is missing these RSVP proxy features. When Puuskari 
describes the mobile as setting "break bits" at col. 16, lines 5-8 ("the GGSN, or an external host, 
and the MS on the other side, may act like some fixed capacity would have been reserved for a 
flow or IP context and can set "break bits" of the RSVP messages, if necessary"), the mobile 
station is clearly RSVP-enabled and does not require an RSVP proxy. 

Claim 8 recites an access point "detecting an indicator in the request message [from the 
mobile terminal] indicating that the access point should function as a communications protocol 
proxy for the mobile terminal for a media data stream of the multimedia session." As explained 
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above, there is no teaching in Puuskari of the mobile station making the determination that it 
needs the GGSN to be its RSVP proxy. Nor does Puuskari teach that the PDP context request 
message (see the text quoted above from column 8 describing Puuskari's PDP context request 
message) includes an RSVP proxy flag "indicating that the access point should function as a 
communications protocol proxy for the mobile terminal for a media data stream of the 
multimedia session." Similar features are found in claim 25. 

Claim 18 is directed to a mobile terminal that "determine[s] a need for a conmiunications 
protocol proxy for the mobile terminal for the multimedia session" and sends a PDP context 
request message with RSVP proxy flag indicating that the access point should function as a 
communications protocol proxy for the mobile terminal for the media data stream of the 
multimedia session. In the system claim 38, "the mobile terminal determines a need for a 
communications protocol proxy for the mobile terminal for the multimedia session " and sends a 
PDP context request message to the GGSN with a RSVP proxy flag asking the GGSN to be the 
mobile terminal's RSVP proxy during the multimedia session. Puurskari lacks these features for 
reasons explained above. 

The application is now in condition for allowance. An early notice to that effect is 
requested. 
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